Network Working Group D. Papadimitriou, Ed. 
Request for Comments: 4328 Alcatel 
Updates: 3471 January 2006 
Category: Standards Track 


Generalized Multi-Protocol Label Switching (GMPLS) 
Signaling Extensions for G.709 Optical Transport Networks Control 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
This document is a companion to the Generalized Multi-Protocol Label 
Switching (GMPLS) signaling documents. It describes the technology- 
specific information needed to extend GMPLS signaling to control 
Optical Transport Networks (OTN); it also includes the so-called 
pre-OTIN developments. 
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1. Introduction 


Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 
MPLS from supporting Packet Switching Capable (PSC) interfaces and 
switching to include support of four new classes of interfaces and 
switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), 
Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional 
description of the extensions to MPLS signaling that are needed to 
support these new classes of interfaces and switching is provided in 
[RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and 
mechanisms needed to support all four classes of interfaces. 


This document presents the technology details that are specific to 
G.709 Optical Transport Networks (OTN) as specified in the ITU-T 
G.709 recommendation [ITUT-G709] (and referenced documents), 
including pre-OTN developments. Per [RFC3471], G.709 technology- 
specific parameters are carried through the signaling protocol in 
dedicated traffic parameter objects. 


The G.709 traffic parameters defined hereafter (see Section 3.2) MUST 
be used when the label is encoded as defined in this document. 
Moreover, the label MUST be encoded as defined in Section 4 when 
these G.709 traffic parameters are used. 


In the context of this memo, by pre-OIN developments, one refers to 
Optical Channel, Digital Wrapper and Forward Error Correction (FEC) 
solutions that are not fully G.709 compliant. Details concerning 
pre-OTN Synchronous Optical Network (SONET)/Synchronous Digital 
Hierarchy (SDH) based solutions including Section/Regenerator Section 
overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH) 
transparency are covered in [RFC3946]. 
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1. 


Te 


xxx Note on ITU-T G.709 Recommendation *** 


The views on the ITU-T G.709 OTN Recommendation presented in this 
document are intentionally restricted to the GMPLS perspective within 
the IETF CCAMP WG context. Hence, the objective of this document is 
not to replicate the content of the ITU-T OTN recommendations. 
Therefore, readers interested in more details concerning the 
corresponding technologies are strongly invited to consult the 
corresponding ITU-T documents (also referenced in this memo). 


Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


In addition, the reader is assumed to be familiar with the 
terminology used in ITU-T [ITUT-G709], as well as [RFC3471] and 
[RFC3473]. Abbreviations used in this document are detailed in 
Appendix 1. 


GMPLS Extensions for G.709 - Overview 


[ITUT-G709] defines several networking layers constituting the 
optical transport hierarchy: 


— with full functionality: 
Optical Transmission Section (OTS) 
Optical Multiplex Section (OMS) 
Optical Channel (OCh) 
- with reduced functionality: 
Optical Physical Section (OPS) 
Optical Channel with reduced functionality (OChr) 


It also defines two layers constituting the digital transport 
hierarchy: 


— Optical Channel Transport Unit (OTUk) 
— Optical Channel Data Unit (ODUk) 


However, only the OCh and the ODUk layers are defined as switching 
layers. Both OCh (but not OChr) and ODUk layers include the overhead 
for supervision and management. The OCh overhead is transported in a 
non-associated manner (also referred to as the non-associated 
overhead naOH) in the Optical Transport Module (OTM) Overhead Signal 
(OOS), together with the OTS and OMS non-associated overhead. The 
OOS is transported via a dedicated wavelength, referred to as the 
Optical Supervisory Channel (OSC). It should be noticed that the 
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naOH is only functionally specified and as such, it is open to 
vendor-specific solutions. The ODUk overhead is transported in an 
associated manner as part of the digital ODUk frame. 


As described in [ITUT-G709], in addition to the support of ODUk 
mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. 

It refers to the multiplexing of ODUJ (j = 1, 2) into an ODUk (k > j) 
signal, in particular: 


ODU1 into ODU2 multiplexing 
ODU1 into ODU3 multiplexing 
ODU2 into ODU3 multiplexing 
ODU1 and ODU2 into ODU3 multiplexing 


Adapting GMPLS to control G.709 OTN can be achieved by creating: 


— a Digital Path layer, by extending the previously defined 
"Digital Wrapper" in [RFC3471] corresponding to the ODUk 
(digital) path layer. 

— an Optical Path layer, by extending the "Lambda" concept (defined 
in [RFC3471]) to the OCh (optical) path layer. 

— a label space structure, by considering a tree whose root is an 
OTUk signal and leaves the ODUJ signals (k >= j); enabling the 
identification of the exact position of a particular ODUj signal 
in an ODUk multiplexing structure. 


Thus, the GMPLS signaling extensions for G.709 need to cover the 
Generalized Label Request, the Generalized Label as well as the 
specific technology dependent objects included in the so-called 
traffic parameters as specified in [RFC3946] for SONET/SDH networks. 
Moreover, because multiplexing in the digital domain (such as ODUk 
multiplexing) has been specified in the amended version of the G.709 
ITU-T recommendation (October 2001), this document also proposes a 
label space definition suitable for that purpose. Notice also that 
one uses the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical 
Path) layers directly in order to define the corresponding label 
spaces. 


3. Generalized Label Request 


The Generalized Label Request, as defined in [RFC3471], includes a 
common part (i.e., used for any switching technology) anda 
technology dependent part (i.e., the traffic parameters). In this 
section, both parts are extended to accommodate GMPLS Signaling to 
the G.709 transport plane recommendation (see [ITUT-G709]). 
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Sues 


Common Part 


As defined in [RFC3471], the LSP Encoding Type, the Switching Type 
and the Generalized Protocol Identifier (Generalized-PID) constitute 
the common part of the Generalized Label Request. The encoding of 
the RSVP-TE GENERALIZED LABEL REQUEST object is specified in 
[RFC3473] Section 2.1. 


As mentioned above, this document extends the LSP Encoding Type, the 
Switching Type, and G-PID (Generalized-PID) values to accommodate 
G.709 Recommendation [ITUT-G709]. 


-1. LSP Encoding Type 


Because G.709 Recommendation defines two networking layers (ODUk 
layers and OCh layer), the LSP Encoding Type code-points can reflect 
these two layers defined in [RFC3471] Section 3.1 as "Digital 
Wrapper" and "Lambda" code. The LSP Encoding Type is specified per 
networking layer or, more precisely, per group of functional 
networking layers: the ODUk layers and the OCh layer. 


Therefore, an additional LSP Encoding Type code-point for the G.709 
Digital Path layer is defined; it enlarges the existing "Digital 
Wrapper" code-point defined in [RFC3471]. The former MUST be 
generated when the interface or tunnel on which the traffic will be 
transmitted supports G.709 compliant Digital Path layer encoding. 
The latter MUST only be used for non-G.709 compliant Digital Wrapper 
layer(s) encoding. A transit or an egress node (receiving a Path 
message containing a GENERALIZED_LABEL_ REQUEST object) MUST generate 
a PathErr message, with a "Routing problem/Unsupported Encoding" 
indication, if the requested LSP Encoding Type cannot be supported on 
the corresponding incoming interface. 


In the same way, an additional LSP Encoding Type code-point for the 
G.709 Optical Channel layer is defined; it enlarges the existing 
"Lambda" code-point defined in [RFC3471]. The former MUST be 
generated when the interface or tunnel on which the traffic will be 
transmitted supports G.709-compliant Optical Channel layer encoding. 
The latter MUST only be used for non-G.709 compliant Lambda layer (s) 
encoding. A transit or an egress node (receiving a Path message that 
contains a GENERALIZED LABEL REQUEST object) MUST generate a PathErr 
message with a "Routing problem/Unsupported Encoding" indication, if 
the requested LSP Encoding Type cannot be supported on the 
corresponding incoming interface. 
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Consequently, the following additional code-points for the LSP 
Encoding Type are defined: 


Value Type 
12 G.709 ODUk (Digital Path) 
13 G.709 Optical Channel 


Moreover, the code-point for the G.709 Optical Channel (OCh) layer 
will indicate the requested capability of an end-system to use the 
G.709 non-associated overhead (naOH), i.e., the OTM Overhead Signal 
(OOS) multiplexed into the OTM-n.m interface signal. 


3.1.2. Switching Type 


The Switching Type indicates the type of switching that should be 
performed at the termination of a particular link (see [RFC4202]). 


No additional Switching Type values are to be considered in order to 
accommodate G.709 switching types, because an ODUk switching (and 
thus LSPs) belongs to the TDM class, while an OCh switching (and thus 
LSPs) belong to the Lambda class (i.e., LSC). 


Intermediate and egress nodes MUST verify that the value indicated in 
the Switching Type field is supported on the corresponding incoming 
interface. If the requested value can not be supported, the node 
MUST generate a PathErr message with a "Routing problem/Switching 
Type" indication. 


3.1.3. Generalized-PID (G-—PID) 


The G-PID (16 bits field), as defined in [RFC3471], identifies the 
payload carried by an LSP, i.e., an identifier of the client layer of 
that LSP. This identifier is used by the endpoints of the G.709 LSP. 


The G-PID can take one of the following values when the client 
payload is transported over the Digital Path layer, in addition to 
the payload identifiers defined in [RFC3471]: 


— CBRa: asynchronous Constant Bit Rate (i.e., mapping of STM-16/0C- 

48, STM-64/0C-192 and STM-256/0C-768) 

- CBRb: bit synchronous Constant Bit Rate (i.e., mapping of STM- 
16/0C-48, STM-64/0C-192 and STM-256/0C-768) 

— ATM: mapping at 2.5, 10 and 40 Gbps 

- BSOT: non-specific client Bit Stream with Octet Timing (i.e., 
Mapping of 2.5, 10 and 40 Gbps Bit Stream) 

- BSNT: non-specific client Bit Stream without Octet Timing (i.e., 
Mapping of 2.5, 10 and 40 Gbps Bit Stream) 
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- ODUk: transport of Digital Paths at 2.5, 
— ESCON: Enterprise Systems Connection 
- FICON: Fiber Connection 


10 and 40 Gbps 


The G-PID can take one of the following values when the client 

payload is transported over the Optical Channel layer, in addition to 

the payload identifiers defined in [RFC3471]: 

— CBR: Constant Bit Rate STM-64/0C- 
192 and STM-256/0C-768) 

— OTUkK/OTUkKV: transport of Digital Section at 2.5, 


(i.e., mapping of STM-16/0C-48, 
10 and 40 Gbps 


Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are 
encapsulated through the Generic Framing Procedure (GFP), as 
described in ITU-T G.7041, dedicated G-PID values are defined. 


In order to include pre-OIN developments, the G-PID field can take 
one of the values (currently defined in [RFC3471]) when the following 
client payloads are transported over a so-called lambda LSP: 


— Ethernet PHY 
— Fiber Channel 


(1 Gbps and 10 Gbps) 


The following table summarizes the G-PID with respect to the LSP 
Encoding Type: 


Value G-PID Type LSP Encoding Type 
47 G.709 ODUj G.709 ODUk (with k > j) 
48 G.709 OTUk (v) G.709 OCh 
ODUk mapped into OTUk (v) 
49 CBR/CBRa G.709 ODUk, G.709 OCh 
50 CBRb G.709 ODUk 
51 BSOT G.709 ODUk 
52 BSNT G.709 ODUk 
53 IP/PPP (GFP) G.709 ODUk (and SDH) 
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH) 
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH) 
56 ESCON G.709 ODUk, Lambda, Fiber 
57 FICON G.709 ODUk, Lambda, Fiber 
58 Fiber Channel G.709 ODUk, Lambda, Fiber 
Note: Values 49 and 50 include mapping of SDH. 
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The following table summarizes the update of the G-PID values defined 
in [RFC3471]: 


Value G-PID Type LSP Encoding Type 
32 ATM Mapping SDH, G.709 ODUk 
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber 
34 Sonet/SDH G.709 OCh, Lambda, Fiber 
35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber 


3.2. G.709 Traffic Parameters 


When G.709 Digital Path Layer or G.709 Optical Channel Layer is 
specified in the LSP Encoding Type field, the information referred to 
as technology dependent (or simply traffic parameters) is carried 
additionally to the one included in the Generalized Label Request. 


The G.709 traffic parameters are defined as follows: 


0) al 2 3 

0O 1 2-3 4G 6-7 8 9-0 1 23-4 ECH CHE CERN NN 
Abbe hebben bh bebe bb bb 
| Signal Type | Reserved | NMC 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| NVC | Multiplier (MT) | 
Abbe hebben bh bebe hebbt 
| Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 


In this frame, NMC stands for Number of Multiplexed Components, NVC 
for Number of Virtual Components, and MT for Multiplier. Each of 
these fields is tailored to support G.709 LSP requests. 


The RSVP-TE encoding of the G.709 traffic-parameters is detailed in 
Section 6. 


3.2.1. Signal Type (ST) 


This field (8 bits) indicates the type of G.709 Elementary Signal 
that comprises the requested LSP. The permitted values are: 


Value Type 
0 Not significant 
1 ODU1 (i.e., 2.5 Gbps) 
2 ODU2 (i.e., 10 Gbps) 
3 ODU3 (i.e., 40 Gbps) 
4 Reserved (for future use) 
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3 


s2 


5 Reserved (for future use) 
6 OCh at 2.5 Gbps 
7 OCh at 10 Gbps 
8 OCh at 40 Gbps 
9-255 Reserved (for future use) 


The value of the Signal Type field depends on LSP Encoding Type value 
defined in Section 3.1.1 and [RFC3471]: 


- if the LSP Encoding Type value is the G.709 Digital Path layer, 
then the valid values are the ODUk signals (k = 1, 2 or 3). 

- if the LSP Encoding Type value is the G.709 Optical Channel 
layer, then the valid values are the OCh at 2.5, 10, or 40 Gbps. 

- if the LSP Encoding Type is "Lambda" (which includes the pre-OTN 
Optical Channel layer) then the valid value is irrelevant (Signal 


Type = 0). 
- if the LSP Encoding Type is "Digital Wrapper", then the valid 
value is irrelevant (Signal Type = 0). 


Several transforms can be sequentially applied on the Elementary 
Signal to build the Final Signal that is actually requested for the 


LSP. Each transform application is optional and must be ignored if 
zero; this does not include the Multiplier (MT), which cannot be zero 
and must be ignored if equal to one. Transforms must be applied 


strictly in the following order: 


— First, virtual concatenation (by using the NVC field) can be 
optionally applied directly on the Elementary Signal to form a 
Composed Signal 

— Second, a multiplication (by using the Multiplier field) can be 
optionally applied, either directly on the Elementary Signal, or 
on the virtually concatenated signal obtained from the first 
phase. The resulting signal is referred to as Final Signal. 


-2. Number of Multiplexed Components (NMC) 


The NMC field (16 bits) indicates the number of ODU tributary slots 
used by an ODUJ when multiplexed into an ODUk (k > j) for the 
requested LSP. This field is not applicable when an ODUk is mapped 
into an OTUk and irrelevant at the Optical Channel layer. In both 
cases, it MUST be set to zero (NMC = 0) when sent and should be 
ignored when received. 


When applied at the Digital Path layer, in particular for ODU2 
connections multiplexed into one ODU3 payload, the NMC field 
specifies the number of individual tributary slots (NMC = 4) that 
constitute the requested connection. These components are still 
processed within the context of a single connection entity. For all 
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other currently defined multiplexing cases (see Section 2), the NMC 
field is set to 1. 


3.2.3. Number of Virtual Components (NVC) 


The NVC field (16 bits) is dedicated to ODUk virtual concatenation 
(i.e., ODUk Inverse Multiplexing) purposes. It indicates the number 
of ODU1, ODU2, or ODU3 Elementary Signals that are requested to be 
virtually concatenated to form an ODUk-Xv signal. By definition, 
these signals MUST be of the same type. 


This field is set to 0 (default value) to indicate that no virtual 
concatenation is requested. 


Note that the current usage of this field only applies for G.709 ODUk 
LSPs, i.e., values greater than zero, are only acceptable for ODUk 
Signal Types. Therefore, it MUST be set to zero (NVC = 0), and 
should be ignored when received, when a G.709 OCh LSP is requested. 


3.2.4. Multiplier (MT) 


The Multiplier field (16 bits) indicates the number of identical 
Elementary Signals or Composed Signals that are requested for the 
LSP, i.e., that form the Final Signal. A Composed Signal is the 
resulting signal from the application of the NMC and NVC fields to an 
elementary Signal Type. GMPLS signaling currently implies that all 
the Composed Signals must be part of the same LSP. 


This field is set to one (default value) to indicate that exactly one 
instance of a signal is being requested. Intermediate and egress 
nodes MUST verify that the node itself and the interfaces on which 
the LSP will be established can support the requested multiplier 
value. If the requested values cannot be supported, the receiver 
node MUST generate a PathErr message (see Section 6). 


Zero is an invalid value for the MT field. If received, the node 
MUST generate a PathErr message (see Section 6). 


3.2.5. Reserved Fields 
The reserved fields (8 bits in row 1 and 32 bits in row 3) are 
dedicated for future use. Reserved bits SHOULD be set to zero when 
sent and MUST be ignored when received. 


4. Generalized Label 


This section describes the Generalized Label value space for Digital 
Paths and Optical Channels. The Generalized Label is defined in 
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[RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL 
object is specified in [RFC3473] Section 2.3. 


The label distribution rules detailed in Section 4.2 follow (when 
applicable) the ones defined in [RFC3946]. 


4.1. ODUk Label Space 


At the Digital Path layer (i.e., ODUk layers), G.709 defines three 
different client payload bit rates. An Optical Data Unit (ODU) frame 
has been defined for each of these bit rates. ODUk refers to the 
frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), or 
3 (for 40 Gbps). 


In addition to the support of ODUk mapping into OTUk, the G.709 
label space supports the sub-levels of ODUk multiplexing. ODUk 
multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk 
(k > j), in particular: 


- ODU1 into ODU2 multiplexing 
- ODU1 into ODU3 multiplexing 
- ODU2 into ODU3 multiplexing 
- ODU1 and ODU2 into ODU3 multiplexing 


More precisely, ODUJ into ODUk multiplexing (k > j) is defined when 
an ODUJ is multiplexed into an ODUk Tributary Unit Group (i.e., an 
ODTUG constituted by ODU tributary slots) that is mapped into an 
OPUk. The resulting OPUk is mapped into an ODUk, and the ODUk is 
mapped into an OTUk. 


Therefore, the label space structure is a tree whose root is an OTUk 
signal and whose leaves are the ODUJ signals (k >= j) that can be 
transported via the tributary slots and switched between these slots. 
A G.709 Digital Path layer label identifies the exact position of a 
particular ODUj signal in an ODUk multiplexing structure. 


The G.709 Digital Path Layer label or ODUk label has the following 
format: 


0 1 2 3 
012345678901234567890123456789021 
Fat — ta tata taita tata tata tata tata ta E E EE EEN 
| Reserved | t3 KC el 
KE E E E E E EE EE EEN 


Reserved bits MUST be set to zero when sent and SHOULD be ignored 
when received. 
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The specification of the fields tl, t2, and t3 self-consistently 
characterizes the ODUk label space. The value space for the tl, t2, 
and t3 fields is defined as follows: 


Lie td. (LAHI): 
— tl=1 indicates an ODU1 signal. 
— tl is not significant for the other ODUk signal types (i.e., 
tl value MUST be set to 0 and ignored). 


2. t2 (3-bit): 
- t2=1 indicates an ODU2 signal that is not further sub- 
divided. 
- t2=[2..5] indicates the tributary slot (t2th-2) used by the 
ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). 
- t2 is not significant for an ODU3 (i.e., t2 value MUST be 
set to 0 and ignored). 


3. t3 (6-bit): 
- t3=1 indicates an ODU3 signal that is not further sub- 
divided. 
- t3=[2..17] indicates the tributary slot (t3th-1) used by the 
ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). 
- t3=[18..33] indicates the tributary slot (t3th-17) used by 
the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). 


Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required 
to identify the 4 tributary slots used by the ODU2; these tributary 
time slots have to be allocated in ascending order. 


If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j 
> i), the corresponding ODUk signal ODU[i] is directly mapped into 
the corresponding OTUk signal (k=i). This is referred to as the 
mapping of an ODUk signal into an OTUk of the same order. Therefore, 
the numbering starts at 1; zero is used to indicate a non-significant 
field. A label field equal to zero is an invalid value. 


Examples: 

- ¢3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 
- t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 
- t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 


- ¢3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot 
of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 
- ¢3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot 
of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 
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4.2. Label Distribution Rules 


In case of ODUk in OTUk mapping, only one label can appear in the 
Generalized Label. The unique label is encoded as a single 32-bit 
label value (as defined in Section 4.1) of the GENERALIZED LABEL 
object (Class-Num = 16, C-Type = 2). 


In case of ODUJ in ODUk (k > j) multiplexing, the explicit ordered 
list of the labels in the multiplex is given (this list can be 
restricted to only one label when NMC = 1). Each label indicates a 
component (ODUJ tributary slot) of the multiplexed signal. The order 
of the labels must reflect the order of the ODUJ into the multiplex 
(not the physical order of tributary slots). This ordered list of 
labels is encoded as a sequence of 32-bit label values (as defined in 
Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type 
= 2). 


In case of ODUk virtual concatenation, the explicit ordered list of 
all labels in the concatenation is given. Each label indicates a 
component of the virtually concatenated signal. The order of the 
labels must reflect the order of the ODUk to concatenate (not the 
physical order of time-slots). This representation limits virtual 
concatenation to remain within a single (component) link. In case of 
multiplexed virtually concatenated signals, the first set of labels 
indicates the components (ODUj tributary slots) of the first 
virtually concatenated signal, the second set of labels indicates the 
components (ODUj tributary slots) of the second virtually 
concatenated signal, and so on. This ordered list of labels is 
encoded as a sequence of 32-bit label values (as defined in Section 
4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). 

In case of ODUk virtual concatenation, the number of label values is 
determined by the NVC value. Multiplexed ODUk virtual concatenation 
additionally uses the NMC value to determine the number of labels per 
set (equal in size). 


In case of multiplication (i.e., when using the MT field), the 
explicit ordered list of all labels taking part in the composed 
signal is given. The above representation limits multiplication to 
remain within a single (component) link. In case of multiplication 
of multiplexed virtually concatenated signals, the first set of 
labels indicates the components of the first multiplexed virtually 
concatenated signal, the second set of labels indicates components of 
the second multiplexed virtually concatenated signal, and so on. 

This ordered list of labels is encoded as a sequence of 32-bit label 
values (as defined in Section 4.1) of the GENERALIZED_LABEL object 
(Class-Num = 16, C-Type = 2). In case of multiplication of (equal) 
ODUk virtual concatenated signals, the number of label values per 
signal is determined by the NVC value. Multiplication of multiplexed 
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(equal) ODUk virtual concatenation additionally uses the NMC value to 
determine the number of labels per set (equal in size). 


4.3. Optical Channel Label Space 


At the Optical Channel layer, the label space must be consistently 
defined as a flat space whose values reflect the local assignment of 
OCh identifiers that correspond to the OTM-n.m sub-interface signals 
(m = 1, 2 or 3). Note that these identifiers do not cover OChr 
because the corresponding Connection Function (OChr-CF) between OTM- 
nr.m/OTM-Or.m is not defined in [ITUT-G798]. 


The OCh label space values are defined by either absolute values 
(i.e., channel identifiers or Channel ID, also referred to as 
wavelength identifiers) or relative values (channel spacing, also 


referred to as inter-wavelength spacing). The latter is strictly 
confined to a per-port label space, whereas the former could be 
defined as a local or a global (per node) label space. Such an OCh 


label space is applicable to both OTN Optical Channel layer and pre- 
OTN Optical Channel layer. 


Optical Channel label encoding (and distribution) rules are defined 
in [RFC3471]. They MUST be used for the Upstream Label, the 
Suggested Label, and the Generalized Label. 


5. Examples 


The following examples are given in order to illustrate the 
processing described in the previous sections of this document. 


1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 
directly transported in an OTU1 (OTU2 or OTU3), the upstream node 
requests results simply in an ODU1 (ODU2 or ODU3) signal request. 


In such conditions, the downstream node has to return a unique 
label because the ODU1 (ODU2 or ODU3) is directly mapped into the 
corresponding OTU1 (OTU2 or OTU3). Because a single ODUk signal 
is requested (Signal Type = 1, 2 or 3), the downstream node has to 
return a single ODUk label, which can be, for instance, one of the 
following when the Signal Type = 1: 


- ¢3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 
- ¢3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 
- t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 


2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 
into the payload of a structured ODU2 (or ODU3), the upstream node 
requests results simply in an ODU1 signal request. 
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In such conditions, the downstream node has to return a unique 
label because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). 
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or 
OPU3) and then mapped into the corresponding OTU2 (or OTU3). 
Because a single ODU1 multiplexed signal is requested (Signal Type 
= 1 and NMC = 1), the downstream node has to return a single ODU1 
label, which can take, for instance, one of the following values: 


— t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 
- t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 
- t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 


3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 
multiplexed into the payload of a structured ODU3, the upstream 
node requests results simply in an ODU2 signal request. 


In such conditions, the downstream node has to return four labels 
since the ODU2 is multiplexed into one ODTUG3. The latter is 
mapped into an ODU3 (via OPU3) and then mapped into an OTU3. 
Since an ODU2 multiplexed signal is requested (Signal Type = 2, 
and NMC = 4), the downstream node has to return four ODU labels 
which can take for instance the following values: 


- t3=18, t2=0, t1=0 
- ¢3=22, t2=0, t1=0 
- t3=23, t2=0, t1=0 
- t3=26, t2=0, t1=0 


first part of ODU2 in first TS of ODTUG3 
second part of ODU2 in fifth TS of ODTUG3 
third part of ODU2 in sixth TS of ODTUG3 


( 
( 
( 
(fourth part of ODU2 in ninth TS of ODTUG3 


) 
) 
) 
) 


4. When a single OCh signal of 40 Gbps is requested (Signal Type = 
8), the downstream node must return a single wavelength label as 
specified in [RFC3471]. 


5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT) 
value > 1), an explicit list of labels is returned to the 
requestor node. 


When the downstream node receives a request for a 4 x ODU1 signal 
(Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it 
returns an ordered list of four labels to the upstream node: the 
first ODU1 label corresponds to the first signal of the LSP, the 
second ODU1 label corresponds to the second signal of the LSP, 
etc. For instance, the corresponding labels can take the 
following values: 


- First ODU1: t3=2, t2=0, t1=0 
— Second ODU1: t3=10, t2=0, t1=0 
- Third ODU1: t3=7, t2=0, t1=0 
- Fourth ODU1: t3=6, t2=0, t1=0 


in first TS of ODTUG3 
in ninth TS of ODTUG3 
in sixth TS of ODTUG3 


) 
) 
) 
in fifth TS of ODTUG3) 
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6. 


RSVP-TE Signaling Protocol Extensions 


This section specifies the [RFC3473] protocol extensions needed to 
accommodate G.709 traffic parameters. 


The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC 
and FLOWSPEC objects. The same format is used both for SENDER_TSPEC 
object and FLOWSPEC objects. The content of the objects is defined 
above in Section 3.2. The objects have the following class and type 
for G.709: 


— G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 
— G.709 FLOWSPEC Object: Class = 9, C-Type = 5 


There is no Adspec associated with the G.709 SENDER_TSPEC. Either 
the Adspec is omitted or an Int-serv Adspec with the Default General 
Characterization Parameters and Guaranteed Service fragment is used, 
see [RFC2210]. 


For a particular sender in a session, the contents of the FLOWSPEC 
object received in a Resv message SHOULD be identical to the contents 
of the SENDER_TSPEC object received in the corresponding Path 
message. If the objects do not match, a ResvErr message with a 
"Traffic Control Error/Bad Flowspec value" error SHOULD be generated. 


Intermediate and egress nodes MUST verify that the node itself, and 
the interfaces on which the LSP will be established, can support the 
requested Signal Type, NMC, and NVC values (as defined in Section 
3.2). If the requested value(s) cannot be supported, the receiver 
node MUST generate a PathErr message with a "Traffic Control 
Error/Service unsupported" indication (see [RFC2205]). 


In addition, if the MT field is received with a zero value, the node 
MUST generate a PathErr message with a "Traffic Control Error/Bad 
Tspec value" indication (see [RFC2205]). 
Security Considerations 
This document introduces no new security considerations to [RFC3473]. 
IANA Considerations 
Two values have been defined by IANA for this document: 


Two RSVP C-Types in registry: 


http://www.iana.org/assignments/rsvp-parameters 
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- A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see 
Section 6. 


— A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see 
Section 6. 


IANA will also track the code-point spaces extended and/or updated by 
this document. For this purpose, the following new registry entries 
have been added in the newly requested registry entry: 
http://www.iana.org/assignments/gmpls-sig-parameters 


- LSP Encoding Type: 
Name: LSP Encoding Type 
Format: 8-bit number 


Values: 
FE tl defined in [RFC3471] 
12 defined in Section 3.1.1 
13 defined in Section 3.1.1 
Allocation Policy: 
[0..239] Assigned by IANA via IETF Standards Track RFC 
Action. 
[240..255] Assigned temporarily for Experimental Usage. 


These will not be registered with IANA 


- Switching Type: 
Name: Switching Type 
Format: 8-bit number 
Values: defined in [RFC3471] 
Allocation Policy: 
[0..255] Assigned by IANA via IETF Standards Track RFC 
Action. 


— Generalized PID (G-PID): 
Name: G-PID 
Format: 16-bit number 


Values: 
H SCH) defined in [RFC3471] 
[32.535] defined in [RFC3471] and updated by Section 
3a RI 
[36..46] defined in [RFC3471] 
[47..58] defined in Section 3.1.3 
Allocation Policy: 
IR EE 3] Assigned by IANA via IETF Standards Track RFC 
Action. 


[31744..32767] Assigned temporarily for Experimental Usage 
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[32768..65535] Not assigned. Before any assignments can be 
made in this range, there MUST be a Standards 
Track RFC that specifies IANA Considerations 
that covers the range being assigned. 


Note: per [RFC3471], Section 3.1.1, standard Ethertype values are 
used as G-PIDs for packet and Ethernet LSPs. 
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Appendix A. 


BSNT 
BSOT 
CBR 
ESCON 
FC 
FEC 
FICON 
FSC 
GCC 
GFP 
LSC 
LSP 
MS 
naOH 
NMC 
NVC 
OCC 
OCG 
OCh 
OChr 
ODTUG 
ODU 
OH 
OMS 
OMU 
OOS 
OPS 
OPU 
OSC 
OTH 
OTM 
OTN 
OTS 
OTU 
OTUkKV 
PPP 
PSC 
RES 
RS 
TTI 
TDM 
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Abbreviations 


Bit Stream without Octet Timing 
Bit Stream with Octet Timing 
Constant Bit Rate 

Enterprise Systems Connection 
Fiber Channel 

Forward Error Correction 

Fiber Connection 

Fiber Switch Capable 

General Communication Channel 
Generic Framing Procedure 
Lambda Switch Capable 

Label Switched Path 

Multiplex Section 
non-associated Overhead 

Number of Multiplexed Components 
Number of Virtual Components 
Optical Channel Carrier 

Optical Carrier Group 

Optical Channel (with full functionality) 
Optical Channel (with reduced functionality) 
Optical Date Tributary Unit Group 
Optical Channel Data Unit 
Overhead 

Optical Multiplex Section 
Optical Multiplex Unit 

OTM Overhead Signal 

Optical Physical Section 
Optical Channel Payload Unit 
Optical Supervisory Channel 
Optical Transport Hierarchy 
Optical Transport Module 
Optical Transport Network 
Optical Transmission Section 
Optical Channel Transport Unit 
Functionally Standardized OTUk 
Point to Point Protocol 

Packet Switch Capable 

Reserved 

Regenerator Section 

Trail Trace Identifier 

Time Division Multiplex 
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Appendix B. G.709 Indexes 


— Index k: The index "k" is used to represent a supported bit rate 
and the different versions of OPUk, ODUk and OTUk. k=1 represents an 
approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit 
rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k = 
4 an approximate bit rate of 160 Gbit/s (under definition). The 
exact bit-rate values are in kbits/s: 


OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 
ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 
OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 


— Index m: The index "m" is used to represent the bit rate or set of 
bit rates supported on the interface. This is a one or more digit 
"k", where each "k" represents a particular bit rate. The valid 
values for m are (1, 2, 3, 12, 23, 123). 


— Index n: The index "n" is used to represent the order of the OTM, 
OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 
of wavelengths that can be supported at the lowest bit rate supported 
on the wavelength. It is possible that a reduced number of higher 
bit rate wavelengths are supported. The case n=0 represents a single 
channel without a specific wavelength assigned to the channel. 


- Index r: The index "r", if present, is used to indicate a reduced 
functionality OTM, OCG, OCC and OCh (non-associated overhead is not 
supported). Note that for n=0 the index r is not required as it 
implies always reduced functionality. 
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